Summary
Timeouts bound how long a caller waits. Retries attempt the operation again after failure or uncertainty.
Interview Points
- Every network call should have a timeout.
- Retries need budgets, backoff, jitter, and idempotency.
- Timeouts prevent resource exhaustion.
- Retrying after a timeout can create duplicate side effects.
- Coordinate timeouts across service chains.
2-3 Minute Interview Script
“A timeout is a boundary: it says how long the caller is willing to wait. A retry is a recovery strategy: it tries again when a failure might be transient.
Timeouts are essential because without them, threads, connections, and user requests can hang indefinitely. But retries must be controlled. Retrying too aggressively can overload a struggling dependency and make an incident worse.
I would use short, realistic timeouts, bounded retries, exponential backoff, jitter, and idempotency for operations with side effects. I would also ensure upstream timeouts are longer than downstream timeouts so failures propagate cleanly.
Interview line: timeout protects resources; retry improves success for transient failure.”
Follow-Ups
- Why are retry budgets useful?
- How do side effects affect retry design?